ASCII CHARACTERS 128 TO 255 INPUT CHARACTERS IN PILOT The ACCEPT statement allows codes 32 to 255 to be entered as part of student replies. Characters in this range are echoed to the display so that the student sees what has been typed. Characters from 0 to 31 are reserved for special purposes; specifically, character 13 is the RETURN character which signals the end of the student reply. Character 8 is a backspace character which may be used to back up and correct typing errors. And character 3 (ctrl-C) cancels a PILOT program immediately. Other characters in the range 0 to 31 are completely ignored by the ACCEPT statement (unless it is an ACCEPT-SINGLE, AS: in which case all codes other than ctrl-C may be entered). BASIC appendix G, pages G2 and G3, show the codes generated for most of the normal printable character keys on the keyboard. The chart below shows the codes generated for the various special keys on the keyboard. DEFAULT KEYBOARD CODES ON AN ACCEPT STATEMENT 128-131 alt- 9 0 - = 132 ctrl-pg up 143 shift-tab 144-153 alt- Q W E R T Y U I O P 158-166 alt- A S D F G H J K L 172-178 alt- Z X C V B N M 187-196 f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 199 home 200 cursor up 201 pg up 203 cursor left 205 cursor right 207 end 208 cursor down 209 pg dn 210 ins 211 del 212-221 shift- f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 222-231 ctrl- f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 232-241 alt- f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 242 ctrl-prtsc 243 ctrl-cursor left 244 ctrl-cursor right 245 ctrl-end 246 ctrl-pg dn 247 ctrl-home 248-255 alt- 1 2 3 4 5 6 7 8 HOW TO CHANGE KEYBOARD VALUES The NX: statement allows the program to change the code generated by any key from the value shown in the above table (or in BASIC appendix G) to any other value from 0 to 255. In this manner the student can be informed regarding an alternate use of the keys when responding. Thus the following statements would make sense. NX:153,227 T: Dear student, : If you wish to reply with the Greek letter : PI in any of your answers hold down the : ALT key while pushing the P key. After the above NX: statement, any time the student typed ALT-P, character 227 would be entered into the answer buffer and (assuming screen mode 0-3) the letter PI would appear on the screen. The ability to re-define the keyboard keys allows the student to answer with any characters the program writer has chosen. The AX: op code can be used to make the keys temporarily act like their normal defaults when it is necessary to be able to use the keyboard in two ways depending on the context. 192 @ 224 ` 193 A 225 a 194 B 226 b 195 C 227 c 196 D 228 d 197 E 229 e 198 F 230 f 199 G 231 g 200 H 232 h 201 I 233 i 202 J 234 j 203 K 235 k 204 L 236 l 205 M 237 m 206 N 238 n 207 O 239 o 208 P 240 p 209 Q 241 q 210 R 242 r 211 S 243 s 212 T 244 t 213 U 245 u 214 V 246 v 215 W 247 w 216 X 248 x 217 Y 249 y 218 Z 250 z 219 [ 251 { 220 \ 252 | 221 ] 253 } 222 ^ 254 ~ 223 _ 255 Alt-8 Appendix C. STUDENT RECORDS The File In, File Out and Keep statements can be used in many combinations to perform custom student record keeping. The unique needs of any program can be accommodated by programming the desired record keeping functions into the program. There are however, several typical record keeping functions that may occur in substantially the same form over and over. Since these needs arise repeatedly PILOT provides a set of simple macros which can be used to include student record keeping in a program with minimal effort. To use these macros, the author would include them at the appropriate points in the program via the F7 key of the EZ editor. RESTART MACROS The term "restart" implies that the student may leave the program prior to completion, and may resume at the same point in the program at a later time. These macros are used to build a student restart file which contains the student's id number, name, and the point at which the student should resume upon return to the program. These macros also provide for the preservation of data about the student's progress. The size and nature of that data is up to the programmer. To use these two macros it is necessary to include the "RESTART.PIM" macro in the initialization section of the program. Then the "CHECKPT.PIM" macro is included at every point within the program where the student might be permitted to resume upon return. If the program is a series of distinct problems, the start of each problem might be considered to be a check point. PROGRAM ORGANIZATION The organization of the program should be as follows: RESTART macro expanded here . . . CHECKPT macro expanded here CHECKPT macro expanded here CHECKPT macro expanded here . . . CHECKPT macro expanded here THE RESTART.PIM MACRO Prior to the RESTART macro, use EZ to write your dimension statements, set the screen modes, etc, and perform any initial code which would need to be done for any student whether returning to the program or starting for the first time. Then, still in EZ, position after the above statements, push F7 and enter the name RESTART.PIM. The RESTART macro prompts for two parameters. The first is the name of the file to be used for keeping student data. You can enter any valid file name or just push the ENTER key to use the default file name "RESTART". The second prompt requests the size of the user data area to be set aside in each student record. This area is used to store any data your program might need to keep about a student. The restart macro records this data at each check point and restores it upon each program restart. The programmer can choose to retain from 0 to 500 bytes of student data. In the simplest case just push ENTER to indicate that no optional student data area is needed. Once the two parameters are entered the RESTART macro expands about 3 screens of PILOT code. When the program is executed, the code asks for the student ID, and name. It maintains the restart file and handles the branching of the student to the appropriate restart point upon return. THE CHECKPT.PIM MACRO Next, determine which points within the program are check points. A student always resumes at the last check point passed prior to leaving the program. At the start of each section which is to be a check point, use the F7 key and enter the name CHECKPT.PIM. This macro expands the code necessary to save the student restart data at that point so that restart can function. It is completely up to the programmer to determine how many check points are placed in the program, and where they are placed. Each time the student reaches a check point the location of the check point and the current value of the user data variable UDAT$ is recorded in the restart file under that student's id. When a student starts the program, the student's id number is used to look up the student record. The value of the user data variable UDAT$ is restored from the last data saved in the student record, then a Jump is performed to the last check point location saved for that student. SAVING USER DATA The program can use the restart facility to save data about the student from one run to the next. To do so, when entering the RESTART macro, indicate the number of bytes to be reserved in each student record for optional data. The number may be from 1 to 500. The actual amount is up to the programmer. This data is saved and restored by the restart facility but its actual use in the program is determined only by how the programmer uses the data. The restart macro creates a string variable called UDAT$ which has a maximum length equal to the size specified for optional user data. Each call to the CHECKPT macro causes the current contents of UDAT$ to be recorded in the student's record on disk. When a student returns to the program the last value saved for UDAT$ is restored to the variable UDAT$ prior to jumping to the instruction just after the CHECKPT. The program can place any data within the string UDAT$ prior to each call to CHECKPT. And, if necessary the data can be moved from UDAT$ to other variables just after each call to CHECKPT. THE RESTART FILE The student record file is in ascii text format and contains one line per student. Each line contains a 10 byte field for student id number, a 30 byte field for name, a 10 byte field for the last check point label, from 1 to 500 bytes of optional user data, a return character and a line feed character. To list the file on the display enter the command: TYPE RESTART To print the student record file enter the command: COPY RESTART PRN: Appendix D. GRAPHIC IMAGE PROCESSING The PILOT GX: command can be used to display a graphic image stored in a disk file. The GX: command accepts an image in BSAVE format, so called because it is the format that is produced by the BASIC language BSAVE command. There are some limitations to this format and the GX: command. First, only the original CGA modes, 0 through 6 are supported, not the higher resolution modes of the EGA. Second, the pictures are stored as uncompressed bit mapped images, so each picture occupies 16K on disk regardless of the complexity of the picture. Third, the GX: command always displays the entire picture, and does not use any special effects in the display. PILOT includes a set of utilities to address these limitations. These utilities permit the author to: Import a picture created by a graphics programs for display from within a PILOT lesson. Store the picture on disk in a compressed format which reduces the storage requirements. Display a picture in any graphics mode, including the EGA high resolution modes. Display an entire picture, or any portion of the picture. When a portion of a picture is displayed, it may be positioned anywhere on the display. Display the picture using a variety of special effects, such as horizontal and vertical wipes or fades. The user must distinguish between pictures which will be displayed in low resolution modes (4, 5 and 6) and those which will be displayed in EGA modes (13, 14 and 16). For the low resolution modes, pictures are 320 by 200 pixels, 4 colors. PILOT programs expect these pictures to be in PIQ format. A picture to be used in a low resolution mode can be created with the GIE program which is included with PILOT, via a PILOT program which saves the picture via the GSX: statement, or by capturing the image from another program with the BSAVER utility. These image files can be compressed and stored in PIQ format via the PIQCMPRS utility. PIQCMPRS can also be used to convert a .PCX file created via PC/Paintbrush to PIQ format. Then the images may be displayed in a PILOT program via the PIQI, PIQS and PIQF macros. For EGA high resolution modes, pictures can be up to 640 by 350, 16 colors. PILOT programs expect these pictures to be in PCX format as produced by PC/Paintbrush (trademark of Zsoft Corporation). These pictures can be created with PC/Paintbrush (installed for EGA mode), or by using the FRIEZE utility program (part of Paintbrush) to capture a screen image from another program. Since this format is already in a compressed form, PILOT does not require any further processing of the picture, it can be called up from a PILOT program in exactly the form created by Paintbrush. These images can be displayed in a PILOT program via the EGAPIQI and EGAPIQ macros. The various utilities for managing graphic images of both types are described below. LOW RESOLUTION PICTURES Low resolution pictures can be used on an IBM Color Graphics Adapter (CGA) or Extended Graphics Adapter (EGA). These pictures are displayed in PILOT screen modes 4, 5 or 6. To use a picture of this form in your PILOT program follow these steps: Create the picture with GIE, or via a PILOT program GSX: command, or with PC/Paintbrush (installed for 320 by 200 mode), or via the BSAVER capture utility. Run the PIQCMPRS utility to convert and compress the picture to PIQ format. Use the EZ editor to expand the PIQI, PIQF and/or PIQS macros into your PILOT program. The BSAVER Utility The file BSAVER.EXE contains the BSAVER utility. It can be used to capture a graphic image from any program which operates in 320 by 200 screen mode (CGA graphics mode). To use BSAVER you first load it into RAM via the command BSAVER This does not cause anything visible to happen. Rather, BSAVER loads into memory and remains there until called up later. Having loaded BSAVER, execute the graphics program with which you will create the picture. Run it normally until the picture you wish to capture is displayed. Then push the PRTSC key (while holding down SHIFT). BSAVER wakes up and displays a prompt on the top of the screen. The prompt shows the file name BSAVER will use to save the current screen display. You can continue by pressing Enter, or you can type another file name to use. BSAVER increments the file name so that it is convenient to use it to capture a series of pictures without entering a new file name for each. The files created by BSAVER are in BSAVE format. These files can be processed by GIE, by the PILOT GX: command, or by the PIQCMPRS utility. If the image captured by BSAVER is a text mode image, it can be used directly in a PILOT program by setting the appropriate screen mode, and referring to the file via the GX: command. Though the same method would work for a graphics mode image, it is reccommended that the image be converted first to PIQ format. This saves space and enhances the possible display options. The PIQCMPRS Utility This utility is used to convert a BSAVE or PCX format picture to PIQ format. It is valid for CGA graphics modes only, 320 by 200, 4 color. To use it enter the command: PI PIQCMPRS Then follow the prompt to enter the name of the input file. If the input file name ends in ".PCX", it is assumed to be in PC/Paintbrush format. Otherwise it is assumed to be in BSAVE format. The graphic image is then saved in a file with a suffix of ".PIQ". The PIQI, PIQS, PIQF and GETFILE Macros These macros can be included in your PILOT program to display pictures which have been prepared via the PIQCMPRS utility. The EZ editor is used to expand these macro calls in your program. To expand a macro, move the cursor to the desired position in the program file and push the F7 function key. Then enter the macro name (complete with the .PIM suffix). Then respond to each prompt as necessary. The use of each macro is detailed below. PIQI.PIM The PIQI macro must be expanded toward the start of the program. It reads in the binary file PIQSHOW.BIN and prepares for display of PIQ images. PIQI need only be executed once per program. The file PIQSHOW.BIN must be present with the program when it is executed. The macro files need only be present when the program is written. PIQF.PIM Once the PIQI macro has been executed once, any number of PIQF macros can be used. The PIQF macro causes the display of a picture, stored in a PIQ file. To use PIQF push the F7 function key in EZ, and enter the name PIQF.PIM. The following parameters must be entered in response to the PIQF prompts: Filename Here enter the name of the image file. Though the file name is of the form nnn.PIQ, do not enter the ".PIQ" suffix. Just enter the first part of the file name. Wipe (C, D, E, F, H, I, L, R, U, V) This selects the manner in which the image is painted onto the screen. One of the following letters must be entered : C is from upper left corner. D is down, from top to bottom. E is explode from center out. F is a fade in. H is a horizontal spilt towards both edges. I is implode from edges inward. L is from right to left. R is from left to right. U is up from bottom to top. V is vertical spilt from center to top and bottom. Option: Xor Mode or Border Color This prompt permits input of additional wipe information. It may be used to specify the XOR option on any wipe except the fade. The xor option causes the image to be blended with the existing display rather than to overlay it. A second possibility for this prompt is to specify a number 0, 1, 2 or 3 for the down or right wipes. The number indicates that a border is to precede the down or rightward wipe. The number indicates the color of the border. If neither the xor or border option is desired, this reply may be left blank. Change Window Parameters This prompt requests a y (for yes) or n (for no) response. In fact, any response except y is taken as a no. The window parameters determine whether the entire picture, or just part of the picture is to be displayed. A no response indicates that the last window parameters executed on any PIQF or PIQS macro are to be used again. The default setting when the program begins causes the entire image to be displayed. A yes response causes four additional prompts for the window boundaries: leftmost column (0-39), rightmost column (0-39), top row (0-24) and bottom row (0-24). Change Position Parameters This prompt requests a y or n response. The position parameters can be used when a partial image is displayed to place the partial image at any screen location. A no response indicates that the last position parameters executed on any PIQF or PIQS macro are to be used again. A yes response causes two additional prompts for the new position: leftmost column (0-39) and top row (0-24). Delay Time (0-254) This parameter controls the speed at which the special effect is performed. 0 indicates maximum speed, which with a D wipe is the fastest display possible. As the delay time is increased, the speed is decreased. PIQS.PIM PIQS, like PIQF, is used to display a PIQ image. PIQF is used to read the image from a file, then display it. PIQS is used to display an image which has previously been read into a string variable. PIQS is useful when one image is to be displayed repeatedly since it can avoid the overhead of re- reading the image from disk. It can also be used when several images are to be displayed in rapid succession since all the images could be pre-read from disk prior to the display of the first image. To use PIQS the program must first have loaded the image file into a string variable via the GETFILE macro. The prompts for PIQS are similar to those for PIQF except that rather than entering the name of a file containing the image, the author must enter the name of a string variable containing the image. GETFILE.PIM The GETFILE macro can be used to create a string variable and read the contents of a disk file into the string variable. It can be used to read in a PIQ image, a sprite table, a binary subroutine, or other data. Its use in conjunction with PIQ images is to pre-load a picture prior to using the PIQS macro. The PIQ Binary Files There are several binary files associated with PIQ image processing. Each is of the form "PIQnnn.BIN". The only file which needs to be distributed with the final PILOT program is PIQSHOW.BIN. The other binary files, as well as the PIQ macro files need be present only when writing the program. HIGH RESOLUTION PICTURES High resolution pictures can be used only on an IBM Extended Graphics Adapter (EGA), not on a Color Graphics Adapter (CGA). This facility can be used to display pictures in PILOT screen modes 13, 14 and 16. To display a picture it must be created via PC/Paintbrush using the corresponding screen mode. To use a picture of this form in your PILOT program follow these steps: Use PC/Paintbrush (installed for an EGA color mode) to draw a picture. Save it in the normal manner. Or, use the FRIEZE utility to capture an image from another program in an EGA mode. Use the EZ editor to expand the EGAPIQI and EGAPIQ macros into your PILOT program. The EGAPIQI and EGAPIQ Macros These macros can be included in your PILOT program to display pictures which are in PCX format for EGA screen modes. The EZ editor is used to expand these macro calls in your program. To expand a macro, move the cursor to the desired position in the program file and push the F7 function key. Then enter the macro name (complete with the .PIM suffix). Then respond to each prompt as necessary. EGAPIQI.PIM The EGAPIQI macro must be expanded toward the start of the program. It reads in the binary file EGAPIQ.BIN and prepares for display of EGAPIQ images. EGAPIQI need only be executed once per program. The file EGAPIQ.BIN must be present with the program when it is executed. The macro files need only be present when the program is written. EGAPIQ.PIM The EGAPIQ macro may be used at any point in a program to display an EGA mode picture. EGAPIQI must have been executed prior to EGAPIQ. To use EGAPIQ push the F7 function key in EZ, and enter the name EGAPIQ.PIM. The following parameters must be entered in response to the EGAPIQ prompts: Filename Here enter the name of the image file. Though the file name is of the form nnn.PCX, do not enter the ".PCX" suffix. Just enter the first part of the file name. Wipe (D, F, L, R, U) This selects the manner in which the image is painted onto the screen. One of the following letters must be entered : D is down, from top to bottom. F is a fade in. L is from right to left. R is from left to right. U is up from bottom to top. Change Window Parameters This prompt requires a y (for yes) or n (for no) response. In fact, any response except y is taken as a no. The window parameters determine whether the entire picture, or just part of the picture is to be displayed. A no response indicates that the last window parameters executed on any EGAPIQ macro are to be used again. The default setting when the program begins causes the entire image to be displayed. A yes response causes four additional prompts for the window boundaries: leftmost column (0-79), rightmost column (0-79), top row (0-24) and bottom row (0-24). Change Position Parameters This prompt requires a y or n response. The position parameters can be used when a partial image is displayed to place the partial image at any screen location. A no response indicates that the last position parameters executed on any EGAPIQ macro are to be used again. A yes response causes two additional prompts for the new position: leftmost column (0-79) and top row (0-24). Delay Time (0-254) This parameter controls the speed at which the special effect is performed. 0 indicates maximum speed, which with a D wipe is the fastest display possible. As the delay time is increased, the speed is decreased. Appendix E. LARGE COMPUTER SIMULATION With PILOT, a simulation program can be created to provide effective operator practice and training on the operation of a large scale computer system operator's console. Such a simulation can be used as in inexpensive substitute for the actual mainframe system for training purposes. Program example SAMPLE12.PIL is an example, derived from an actual full scale simulator, which shows how this type of program might be developed with PILOT. The goal of a simulator is to provide the user with a simulated copy of the target computer system that allows for practical hands-on training in a controlled environment. Though this example simulates a mainframe computer console, similar technics could be used to simulate other systems. Advantages of simulation include the ability to train operators and users before a machine is installed, or to train new personel without tying up the actual system. After a simulator is built, much of the same code might be used in a companion tutorial program which, together with the simulator would make up a complete training package. One approach for simulation of hardware systems is to build a complete simulator first, then build various tutorial modules to allow for task skills to be practiced be entering the simulator at different points. The entry modules would thus set up the environment of the simulator for each new task to be learned. After that task is practiced the student could return to the tutorial for more instruction. Building the Simulator Most mainframe systems accept command sequences that an operator uses to configure, start, stop, initialize control programs, and control the hardware of the machine from a console. Each screen of control information is called a 'frame'. When any particular frame is displayed, there are certain keyboard actions that operator might perform. Some actions move to another frame, others might invoke commands unique to this frame, and yet others migh invoke actions that are available from many different contexts. A convenient organization of the simulator program is to write a separate PILOT program module for each frame to be displayed and it's associated control code. Each file would also contain the necessary code to accept keyboard input and perform the appropriate actions such as link to other frames. An alternate approach is to build each frame as a separate file without the control code. Thus, you would have a set of files that contain only the text to be displayed and the control code in another file. The second approach may be more efficient in the use of space because of the reduction of duplicate routines. Yet, if space is not a concern, you will find it much easier to use the first approach where debugging and controlling your program become less of a task. In either approach, a careful study and understanding of the machine to be simulated is required. For each frame, you should also be able to simulate incorrect actions as well as correct actions. Make note of the real machine's messages and displayed actions for every possible operator command. An action taken on one frame may effect the information displayed on another frame. The frame text that can be changed or effected by student commands will have to be represent by variables called frame variables. Frame variables will have to be set to an initial value in your entry module. This gives you the ability to set the initial status or condition of the machine to be simulated. It also allows you to break apart specific tasks you would like to have the student accomplish. Development Tasks The following sequence of tasks may be helpful in building your machine simulator: Study the operation of the target machine. Make note of incorrect actions as well as correct actions. Determine the machine frames to be simulated. Create a separate text file (nnnn.PIL) for each frame to be displayed. In the text file type an exact copy of the frame display screen. In naming your frame files, choose names which aid in the identification of the associated frames. After you have created the text file, insert PILOT's (T:) command to type the text to the screen. Most machine frames will have an area designated as the command line where the blinking cursor is located awaiting response. This can be accomplished using the (TS:gx,y) command. Use the ACCEPT (A:) command to wait for a response to be evaluated. Determine the machine commands that cause one frame to link to other frames. In some cases, an INDEX key on the console may have to be simulated by use of the ALT key. Some frames may not link to other frames directly, yet have to go to a menu or index frame first. Using PILOT's SYSX routine may be of benefit here. In either case, MATCH statements or use of the function keys should direct the program to a LINK command (L:) that links the frame to another. Once this is accomplished for one frame, much of the same code can placed in the other frame files. Determine the frame variables for each frame. Frame text that is changed or effected by commands should be identified. Once identified, you must create a variable name that represents that text item. Use caution in selecting variable names. Try to chose a name that can be easily associated with the text or function simulated. Remember you must first dimension a string variable before using it. The variable length is set when you Dimension (D:) the variable. Next replace the text items with the appropriate variable names using ($var$) within the frame text. Once the initial value of the variables is set in your entry module, you can change them using the COMPUTE (C:) command. Determine other machine commands that require simulation. First, ensure you have a list of the commands to be simulated or acted upon from the command line. Then create MATCH (M:) statements for each of the possible commands. Next determine what all should happen if a MATCH would occur. Frame variables can be changed by using the Compute on condition Yes statement (CY:). Other variables may change depending on contents of other variables. For example, you may need a way to change a variable only if it's content had a particular string value. CY(var1$="content"):var$="new content" Determine error messages, not simulated commands and simulator messages to be used. Although the goal is to provide a real as possible environment, it may not be practical to simulate every possible command or response. In those cases, the author may want to provide error handling routines that provide a " Message from the Simulator" to be displayed on a predetermined area of the screen. For example, a message might be "Message from Simulator -- Command not known or not simulated " or "Simulated at greater than normal speed." Test the simulator next to the real machine. This will allow you to see many things that you may not have noticed before. Next, ensure your entry modules are task oriented. You can provide a workbook that directs the student to try certain tasks and asks them what has changed or taken place. Sample Machine Simulator Program The SAMPLE12.PIL, and SAMPLE13.PIL files contains an example of a machine simulator that presents an Operator control frame similar to those on many IBM systems. Try it to see a section of a simulator in action. Appendix F. CALLING EXTERNAL PROGRAMS Using the EXEC facility, a PILOT program can execute another program or DOS command. EXEC permits the program to execute any command line, as if it were entered to the DOS command line prompt. The command could perform DOS functions such as DIR or COPY. It could as easily execute a program written in BASIC or PASCAL, or execute another program product such as a word processor or spread sheet. The called program need not be written in any special manner, it is executed in an environment which is the same as if it were executed via a DOS command line. When the called program terminates, control is returned to the PILOT program which resumes execution at the next statement. To use the EXEC facility the file EXEC.BIN must be present. The GETFILE.PIM macro must be used to load and initialize the EXEC.BIN file. Once this is done any number of calls to EXEC may be performed via the V: statement. To use EXEC in a program follow these steps: Use the EZ editor to expand the GETFILE.PIM macro in the initial portion of the PILOT program. GETFILE.PIM prompts for a file name, enter the name EXEC.BIN. It also prompts for a string name, use the name EXEC$. At any point within the PILOT program use the following statements to call an external program: C:EXEC$(9,80) = "any DOS command line here" V:EXEC$ The string passed to EXEC$ may be any command line, exactly as it would be typed to the DOS command prompt "A>". For example, the following lines perform a directory command. C:EXEC$(9,80) = "DIR" V:EXEC$ The following lines call a BASIC program named "HELLO". C:EXEC$(9,80) = "BASIC HELLO" V:EXEC$ If the command does not execute as expected, then upon return from the V: statement, the following line would display an error code per the DOS Error Return Table found in a DOS manual appendix. T:Return code is #(ASC(EXEC$(3))) As an additional return, EXEC$ returns the drive letter in which the file COMMAND.COM was found in string position EXEC$(4). This information might be useful in determining whether a program is executing from floppy or fixed disk. Appendix G. SUPPLEMENTAL MATERIALS This section describes various other printed and program materials that may be useful in PILOT program authoring. ADCIS The "Association for the Development of Computer-Based Instructional Systems" has a PILOT Language Special Interest Group. This association holds annual meetings and publishes newsletters and the "Journal of Computer-Based Instruction". ADCIS national offices can be reached at (206) 676-2860. WCS Washington Computer Services, the developer of PILOT, publishes several products and services for PILOT users: UPDATE SERVICE - New releases of PILOT are supplied. ADVANCED FEATURE LIBRARY - A package of utilities, special device drivers and useful subroutines to increase productivity for the PILOT programmer. LEARNPI and DESIGNER - A 3-diskette tutorial set, LEARNPI, written in PILOT on PILOT written by George Gerhold and Robert Urso. It covers basic programming and screen design topics. VIDEO SCRIPT EXECUTIVE - VSX is an authoring environment for presentations and lessons which may include video, text, graphics, mouse, touch screen and video. VSX can reduce program development time by isolating the author from programming details. The user can extend the power of VSX by coding in PILOT as necessary. For complete information contact Washington Computer Services directly. Phone: (206) 734-8248. SRA SRA publishes beginner's level self-study course (book and diskette) entitled "Developing Computer-Based Training with PC/PILOT" by Kirk Richardson and Valerie Mock. ASYS ASYS publishes PROPI a complete authoring system which can be used with the PILOT language to provide a comprehensive large-scale authoring environment. ASYS phone: (206) 734-2553.